<div class="tmd-doc">
<p></p>
<h1 class="tmd-header-1">
Go Built-in Slice Manipulations Are Incomplete
</h1>
<p></p>
<h2 class="tmd-header-2">
Lack of a performant way to merge 3+ slices
</h2>
<p></p>
<div class="tmd-usual">
In Go, there are three built-in functions to manipulate slices:
</div>
<p></p>
<div class="tmd-usual">
1. the <code class="tmd-code-span">make</code> function is used to create a slice with specified length and capacity. All the elements are set to zero values. 1. the <code class="tmd-code-span">copy</code> function is used to copy some elements from one slice to another if the two slices have identical element types. 1. the <code class="tmd-code-span">append</code> function is used to append some elements to a base slice and result in a new slice. The base slice might share all of its elements with the new slice or not, depending on whether or not the capacity of the base slice is large enough to hold all the appended elements.
</div>
<p></p>
<div class="tmd-usual">
When the capacity of the base slice if an <code class="tmd-code-span">append</code> function call is not larger enough. the call can be viewed as a way to merge two slices. As the way is built-in, it is performant.
</div>
<p></p>
<div class="tmd-usual">
However, there is not a performant way to merge 3+ slices. The following implementation might be the most performant way to do the task:
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">func merge[S ~[]E, E any](ss ...S) S {
	var n, allNils, k = 0, true, -1
	for i := range ss {
		if m := len(ss[i]); n != 0 {
			n += m
			if n &lt; 0 {
				panic("sum of lengths is too large")
			}
		} else if m &gt; 0 {
			n = m
			allNils = false
			k = i
		} else {
			allNils = allNils &amp;&amp; ss[i] == nil
		}
	}
	if allNils {
		return nil
	}
	if n == 0 {
		return S{}
	}
	
	// Make use of this optimization:
	// https://github.com/golang/go/commit/6ed4661807b219781d1aa452b7f210e21ad1974b
	s := ss[k]
	r := make(S, n)
	copy(r, s)
	r = r[:len(s)]
	ss = ss[k+1:]

	for _, s := range ss {
		r = append(r, s...)
	}
	return r
}
</code></pre>
<p></p>
<div class="tmd-usual">
Generally, a <code class="tmd-code-span">make</code> call will zero the elements allocated during its execution, which is unnecessarily for this particular use case. The implementation does its best to zero as few as possible elements within the <code class="tmd-code-span">make</code> call, by using the mentioned optimization, it doesn't zero the elements in <code class="tmd-code-span">r[:len(ss[0])]</code>, but it still fails to do so for the remaining elements (the ones in <code class="tmd-code-span">r[len(ss[0]):]</code>).
</div>
<p></p>
<div class="tmd-usual">
If the <code class="tmd-code-span">merge</code> function is built-in, then it is able to avoid all the unnecessary element zeroing operations.
</div>
<p></p>
<h2 class="tmd-header-2">
Lack of a clean way to clip slices
</h2>
<p></p>
<div class="tmd-usual">
As mentioned above, an <code class="tmd-code-span">append</code> function call will reuse the backing array of the first slice argument (call it <code class="tmd-code-span">base</code> here) for the result slice if the capacity of <code class="tmd-code-span">base</code> is large enough to hold all the appended elements. For some scenarios, we want to prevent an <code class="tmd-code-span">append</code> call from modifying the elements in <code class="tmd-code-span">base[len(base):]</code> and we achieve this by clipping the capacity of <code class="tmd-code-span">base</code> to its length:
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">var x, y, z T

	... = append(base[:len(base):len(base)], x, y, z)
</code></pre>
<p></p>
<div class="tmd-usual">
Nothing to complain about, except that it is some verbose, in particular when the <code class="tmd-code-span">base</code> expression is verbose, such as
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">	... = append(aValue.Field.Slice[:len(aValue.Field.Slice):len(aValue.Field.Slice)], x, y, z)
</code></pre>
<p></p>
<div class="tmd-usual">
If the <code class="tmd-code-span">base</code> expression is a function call, then we must store the result of a call in a temporary intermediate variable:
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">	base := aFunctionCall()
	... = append(base[:len(base):len(base)], x, y, z)
</code></pre>
<p></p>
<div class="tmd-usual">
We can use the <code class="tmd-code-span">Clip</code> function in the <code class="tmd-code-span">golang.org/x/exp/slices</code> package, but this way is still not clean enough.
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">import "golang.org/x/exp/slices"

	... = append(slices.Clip((base), x, y, z)
	
	... = append(slices.Clip(aValue.Field.Slice), x, y, z)
	
	... = append(slices.Clip(aFunctionCall()), x, y, z)
</code></pre>
<p></p>
<div class="tmd-usual">
I do perfer <a href="https://github.com/golang/go/issues/25638">this proposal</a>, but it has been rejected:
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">aSlice[ : n : ]  // &lt;=&gt; aSlice[ : n : n]
aSlice[m : n : ] // &lt;=&gt; aSlice[m : n : n]
sSlice[ : : ]    // &lt;=&gt; aSlice[ : len(aSlice) : len(aSlice)]
aSlice[m : : ]   // &lt;=&gt; aSlice[m : len(aSlice) : len(aSlice)]
</code></pre>
<p></p>
<div class="tmd-usual">
If the proposal is adopted, then we may just write the code as
</div>
<p></p>
<pre class="tmd-code">
<code class="language-Go">	... = append(base[::], x, y, z)
	
	... = append(aValue.Field.Slice[::], x, y, z)
	
	... = append(aFunctionCall()[::], x, y, z)
</code></pre>
<p></p>
<div class="tmd-usual">
which is much cleaner.
</div>
<p></p>
<p></p>
<h2 class="tmd-header-2">
Lack of a safe way to detect element overlapping of two slices
</h2>
<p></p>
<div class="tmd-usual">
This fact prevents custom Go packages to make perfect implementations for some slice manipulations.
</div>
<p></p>
<div class="tmd-usual">
Some standard packages are using (ever used) unsafe ways to do the job. For example:
</div>
<p></p>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="https://github.com/golang/go/blob/13529cc5f443ef4e242da3716daa0032aa8d34f2/src/slices/slices.go#L466-L479">https://github.com/golang/go/blob/13529cc5f443ef4e242da3716daa0032aa8d34f2/src/slices/slices.go#L466-L479</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="https://github.com/golang/crypto/blob/eec23a3978ad/internal/subtle/aliasing.go#L13-L19">https://github.com/golang/crypto/blob/eec23a3978ad/internal/subtle/aliasing.go#L13-L19</a>
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
These unsafe usages actually don't follow any [valid unsafe use patterns](https://pkg.go.dev/unsafe#Pointer), so they are bad and dangerous implementations.
</div>
<p></p>
</div>
